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Scope 



The present document defines the interface to a modulator for a second generation terrestrial television system 
(DVB-T2). The present document also describes a mechanism to allow the operation of over the air regenerative 
repeaters in SFN or non-SFN networks. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI EN 302 755: "Digital Video Broadcasting (DVB); Frame structure channel coding and 

modulation for a second generation digital terrestrial television broadcasting system (DVB-T2)". 

[2] ETSI TS 102 606: "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) 

Protocol". 

[3] ETSI TS 101 191: "Digital Video Broadcasting (DVB); DVB mega-frame for Single Frequency 

Network (SFN) synchronization". 

[4] ETSI EN 301 192: "Digital Video Broadcasting (DVB); DVB specification for data broadcasting". 

[5] ETSI TS 102 034: "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB 

Services over IP Based Networks". 

[6] IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Applications". 

[7] ISO/IEC 13818-1: "Information technology - Generic coding of moving pictures and associated 

audio information: Systems". 

[8] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 
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2.2 Informative references 

The following referenced documents are not essential to the use of the ETSI deliverable but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 102 831: "Digital Video Broadcasting (DVB); Implementation guidelines for a second 

generation digital terrestrial television broadcasting system (DVB-T2)". 

[i.2] CEN EN 50083-9: "Cable networks for television signals, sound signals and interactive 

services - Part 9: Interfaces for CATV/SMATV headends and similar professional equipment for 
DVB/MPEG-2 transport streams". 

[i.3] DVB BlueBook Al 15: "DVB AppUcation Layer EEC Evaluations". 

[i.4] ETSI TR 101 290: "Digital Video Broadcasting (DVB); Measurement guidelines for DVB 

systems". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in [i.l] and the following apply: 

auxiliary stream: sequence of cells carrying data of as yet undefined modulation and coding, which may be used for 
future extensions or as required by broadcasters or network operators 

common PLP: PLP having one slice per T2 frame, transmitted just after the LI signalling, which may contain data 
shared by multiple PLPs 

configurable Ll-signalling: LI signalling consisting of parameters which remain the same for the duration of one 
super-frame 

Coordinated Universal Time (literally Universel Temps Coordonne) (UTC): time format counting in standard SI 
seconds with periodic adjustments made by the addition (or removal) of leap seconds to keep the difference between 
UTC and Astronomical Time less than +0,9 s 

data PLP: PLP of Type 1 or Type 2 

dynamic Ll-signalling: LI signalling consisting of parameters which may change from one T2-frame to the next 

elementary period: time period which depends on the system bandwidth and is used to define the other time periods in 
the T2 system 

FEC Block: set ofN^^^^ OFDM cells carrying all the bits of one LDPC FECFRAME 
FECFRAME: set of A^i^jp^ (16 200 or 64 800) bits fi-om one LDPC encoding operation 
FEF part: part of the super-frame between two T2-frames which may contain (FEFs) 

FFT size: nominal FFT size used for a particular mode, equal to the active symbol period Ts expressed in cycles of the 
elementary period T 

Global Position System (GPS): constellation of satellites providing accurate time and position information to receivers 

GPS Time: time signal broadcast by the GPS satellites using an epoch of January 6'-'^ 1980 with no leap seconds and a 
"week number" (actually a modulo-604 800 seconds number) that wraps every 1 024 weeks (approximately 19,7 years) 



£75/ 



8 ETSI TS 1 02 773 V1 .1 .1 (2009-09) 

interleaving frame: unit over which dynamic capacity allocation for a particular PLP is carried out, made up of a 
integer, dynamically varying number of FEC blocks and having a fixed relationship to the T2 -frames 

NOTE: The Interleaving frame may be mapped directly to one T2-frame or may be mapped to multiple 
T2 -frames. It may contain one or more Tl-blocks. 

International Atomic Time (literally Temps Atomique International) (TAI): time format counting in standard 
SI seconds 

LI pre-signalling: signalling carried in the P2 symbols having a fixed size, coding and modulation, including basic 
information about the T2 system as well as information needed to decode the LI post-signalling 

NOTE: LI pre-signalling remains the same for the duration of a super-frame. 

Ll-post-signalling: signalling carried in the P2 symbol carrying more detailed LI information about the T2 system and 
the PLPs 

MISO group: group (1 or 2) to which a particular transmitter in a MISO network belongs, determining the type of 
processing which is performed to the data cells and the pilots 

NOTE: Signals from transmitters in different groups will combine in an optimal manner at the receiver. 

Modified Julian Date (MJD): date format based on the number of days since midnight GMT on 17*^ 
November 1858 AD 

PI signalling: signalling carried by the PI symbol and used to identify the basic mode of the DVB-T2 symbol 

Physical Layer Pipe (PLP): physical layer TDM channel that is carried by the specified sub-slices 

NOTE: A PLP may carry one or multiple services. 
PLP_ID: this 8-bit field uniquely identifies a PLP within the T2 system, identified with the T2_system_id 

NOTE: The same PLP_ID may occur in one or more frames of the superframe. 

relay (transmitter): transmitter in a network that re-transmits a signal received off-air, either by simple frequency 
transposition or by regenerating the signal 

Time Interleaving block (Tl-block): set of cells within which time interleaving is carried out, corresponding to one 
use of the time interleaver memory 

Type 1 PLP: PLP having one slice per T2 frame, transmitted before any Type 2 PLPs 

Type 2 PLP: PLP having two or more sub-slices per T2 frame, transmitted after any Type 1 PLPs 

T2 frame: fixed physical layer TDM frame that is further divided into variable size sub-slices 

NOTE: T2 frame starts with one PI and one or multiple P2 symbols. 

T2-Gateway: device producing T2-MI at its output, incorporating the functionality of the Basic T2-Gateway and, 
optionally, additional processing such as re-multiplexing 

T2 Super-frame: set of T2 frames consisting of a particular number of consecutive T2 frames 

NOTE: A superframe may in addition include FEF parts. 

T2 system: second generation terrestrial broadcast system whose input is one or more TS or GSE streams and whose 
output is an RF signal 

NOTE: The T2 system: 

■ means an entity where one or more PLPs are carried, in a particular way, within a DVB-T2 signal 
on one or more frequencies. 

■ is unique within the T2 network and it is identified with T2_system_id. Two T2 systems with the 
same T2_system_id and network_id have identical physical layer structure and configuration, 
except for the cell_id which may differ. 
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■ is transparent to the data that it carries (including transport streams and services). 
T2_SYSTEM_ID: this 16-bit field identifies uniquely the T2 system within the T2 network 



3.2 Symbols 



For the purposes of the present document, the symbols given in [i.l] and the following apply: 



T 



The value A^ is expressed in radix x. The radix of x shall be decimal, thus 2Aj^g is the hexadecimal 

representation of the decimal number 42 

Elementary time period for the bandwidth in use 

round towards plus infinity, i.e. the most negative integer greater than or equal to x 



3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in [i.l] and the following apply: 

ACE Active Constellation Extension 

AL Application Layer 

ASI Asynchronous Serial Interface 

BB BaseBand 

bflbf bit-field, left bit first 

bflbfzpb bit-field, left bit first, zero padded after the last bit to a multiple of 8 bits 

CRC Cyclic Redundancy Check 

DFL DataField Length 

DVB Digital Video Broadcasting 

EEC Forward Error Correction 

FEF Future Extension Frame 

EFT Fast Fourier Transform 

GMT Greenwich Mean Time 

GPS Global Positioning System 

GSE Generic Stream Encapsulation 

ID IDentifier 

lERS International Earth Rotation and Reference Systems Service 

IFFT Inverse Fast Fourier Transform 

IP Internet Protocol 

LDPC Low Density Parity Check (codes) 

LoCI Local Content Inserter 

LSB Least Significant Bit 

MEN Multi-Frequency Network 

MISO Multiple Input, Single Output 

MJD Modified Julian Date 

MPEG Moving Picture Experts Group 

MSB Most Significant Bit 

MTU Maximum Transmission Unit 

OFDM Orthogonal Frequency Division Multiplex 

PAPR Peak-to- Average Power Ratio 

PAT Program Association Table 

PID Packet IDentifier 

PLP Physical Layer Pipe 

PMT Program Map Table 

RF Radio Frequency 

RFU Reserved for Future Use 

rms root mean square 

rpchof remainder polynomial coefficients, highest order first 

RTP Real Time Protocol 

SEN Single Frequency Network 

SI Service Information 

T2 DVB-T2 

T2-MI DVB-T2 Modulator Interface 
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T2-MIP DVB-T2 Modulator Information Packet 

TAI International Atomic Time (literally Temps Atomique International) 

TDM Time Division Multiplex 

TFS Time Frequency Slicing 

TI Time Interleaving 

TPH Transport Packet Header 

TS Transport Stream 

UDP User Datagram Protocol 

uimsbf unsigned integer, most significant bit first 

UTC Coordinated Universal Time (literally Universel Temps Coordonne) 

XOR exclusive OR function 



4 General description 

4.1 System overview 

The DVB-T2 specification [1] enables service-specific robustness to be achieved through the use of Physical Layer 
Pipes (PLPs). The allocation of data to each PLP is not however prescriptive and the T2 specification merely states that 
certain constraints must be met. 

To enable Single Frequency Network (SFN) operation, decisions on allocation and scheduling are taken once in a 
T2-Gateway, the results of which are distributed in such a format that each modulator in the network can 
unambiguously create an identical on-air signal. The DVB-T2 Modulator Interface (T2-MI) defines this format and 
allows reliable networks of transmitters (in both MFN and SFN configurations) to be constructed. In addition it supports 
the use of regenerative, off-air repeaters to feed further MFNs and SFNs. 

More information regarding the generation of T2-MI in a T2-gateway and its use by a modulator can be found in [i.l]. 



4.2 System architecture 



The block diagram of a typical DVB-T2 end-to-end chain for Transport Stream input is shown in figure 1 . The T2-MI is 
shown as "Interface B" at the output of the T2-Gateway. 
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Figure 1 : Block diagram of a typical DVB-T2 chain 
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4.3 Protocol Stack 

Figure 2 shows the T2-MI protocol stack. 
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Figure 2: The T2-MI protocol stack 

The DVB-T2 Modulator Interface (T2-MI) carries the DVB-T2 system inputs, MPEG-2 TS and/or Generic Streams, 
encapsulated within DVB-T2 Baseband Frames [1]. 

In addition the T2-MI also carries other data including, but not limited to: 

• LI signalling data to enable the construction of T2 frames by the modulator; 

• IQ vector data for any auxiliary streams; 

• DVB-T2 timestamp (for synchronization); and 

• Future Extension Frame (FEF) data. 

With the exception of the DVB-T2 timestamp, all this information is transmitted as part of the on-air DVB-T2 signal. 

The synchronization timestamp data is not transmitted over-air but used by a modulator to define the precise time of 
emission of the DVB-T2 signal. A special case exists where relay stations forming part of a SEN are fed over air from a 
master station on a different frequency, since they also require access to the synchronization data (see annex B). 

The T2 data is then packetized into T2-MI packets and encapsulated into DVB / MPEG Transport Stream packets using 
Data Piping, in accordance with EN 301 192 [4], clause 4. 

These standard DVB TS packets are then carried either natively over any standard DVB Transport Stream interface, 
such as ASI [i.2], or further encapsulated within IP packets in accordance with TS 102 034 [5] for carriage over IP 
based networks. 



T2-MI packets 



Several different types of T2-related data may be sent over the T2-MI through the use of T2-MI packets. 



5.1 T2-M I packet definition 

The T2-MI packet format is shown in figure 3. 
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T2-MI header 


payload 
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packet_ 
type 


packet_ 
count 
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Figure 3: T2-MI packet format 

Each T2-MI packet is composed of a 6 byte header, followed by a variable-length payload part plus padding, when 
required, and a 32-bit CRC tail for error detection. 

The T2-MI packet consists of the following fields: 

packet_type (8 bits) indicates the type of the payload carried by T2-MI packet. The currently defined values are shown 
table 1 and their associated formats defined in the following clauses. All other values are Reserved for Future Use 
(RFU). 

Table 1 : T2-MI packet types 



T2-MI packet type 


Description 


00i6 


Baseband Frame 


01l6 


Auxiliary stream l/Q data 


10i6 


L1 current 


11l6 


L1 future 


20i6 


DVB-T2 timestamp 


21l6 


Individual addressing 


30i6 


FEF part: Null 


31i6 


FEF part: l/Q data 


all other values 


Reserved for future use 



packet_couiit (8 bits) is incremented by one for each T2-MI packet sent, irrespective of payload. There shall be no 
requirement for the first packet sent to have a specific count value. The counter shall wrap from FFjg to OOjg. 

superframe_idx (4 bits) shall be constant for all T2-MI packets that carry data pertaining to one T2 superframe. It 
should be incremented for each subsequent superframe. No implementation shall require this field to have any particular 
value. 

rfu (12 bits) bits reserved for future use and shall all be set to O2. 
payloadjen (16 bits) indicates the payload length in bits. 

payload {payloadjen bits) carries the T2-MI packet payload which will vary depending on the type of the T2-MI 
packet and is defined in clause 5.2. 

pad (pad_len bits) shall be filled with between and 7 bits of padding such that the T2-MI packet is always an integer 
number of bytes in length, i.e. payload_len+pad_len shall be a multiple of 8. Each padding bit shall have the value O2. 

crc32 (32 bits) is calculated across all other bits in the packet (both header and payload plus any padding), in 
accordance with annex A. 
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5.2 T2-MI payload definitions 



5.2.1 Baseband Frame 

T2-MI packets with a packet_type of OOjg shall carry Baseband Frames, in accordance with [1], clause 5.1.7. 
The T2-MI packet payload is shown in figure 4. 



frame idx 



pipjd 



-8 bits »< 8 bits- 



intl_frame 
start 



-1 bit- 



rfu 



BBFRAME 



(7 bits>K- 



-K^f, bits- 



Figure 4: Baseband Frame payload 



The fields are defined as follows: 



frame_idx (8 bits) indicates the FRAME_IDX, as defined in [1], of the first T2 frame to which the Interleaving Frame 
containing this Baseband Frame is mapped. 

plp_id (8 bits) signals the PLP_ID, as defined in [1], in which the Baseband Frame is to be carried in the DVB-T2 
signal. 

intl_frame_start (1 bit) shall be set to I2 for the packet containing the first BBFRAME of an interleaving frame for a 
particular PLP, and "0" for packets carrying the remaining BBFRAMEs (if any). 

rfu (7 bits) bits reserved for future use and shall all be set to O2. 

BBFRAME (K^^-h bits) carries the ^^ch ^i*-^ °f '■^^ Baseband Frame (before scrambling) pertaining to a particular PLP, 
including the PADDING field if used. It shall be encapsulated into exactly one T2-MI packet without additional 
stuffing. The temporal order of the Baseband Frame bits shall be preserved. If the Baseband Frame PADDING field is 
used for in-band signalling, the relevant bits of the PADDING field shall be set to "0". These shall then be replaced by 
the relevant in-band signalling in the modulator. 

5.2.2 Auxiliary stream l/Q data 

T2-MI packets with a packet_type of 01 jg shall carry auxiliary stream data, in accordance with [1], clause 8.3.7. 
The T2-MI packet payload is shown in figure 4. 



frame idx 



aux id 



rfu 



8 bits-^i<-4 bits->i-<-12 bits-^i< 



aux stream data 



-variabie- 



Figure 5: Auxiliary stream payload 

framejdx (8 bits) indicates the FRAME_IDX, as defined in [1], of the T2 frame which carries the auxiliary stream 
data. 

aux_id (4 bits) indicates the particular auxiliary stream to which the data belongs. The auxiliary streams shall be sent in 
the same order as over the transmitted DVB-T2 signal, starting with aux_id=ljg indicating the first auxiliary stream and 

with the aux_id being incremented by "1" for each new auxiliary stream. The highest possible value is F^g 

corresponding to the 15'*^ auxiliary stream. Other values are reserved for future use. 

rfu (12 bits) bits reserved for future use. 
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aux_streain_data (variable bits) carries the data for each auxiliary stream. It shall consist of the complex cell values in 
order of increasing cell address (as defined in [1]). Each cell value shall be sent as a 12-bit two's complement value /for 
the real part immediately followed by a 12-bit two's complement value Q for the imaginary part of the complex number. 
The cell value, x^ i for use in clause 8.3.7 of [1] shall be given by: 



^(^mj.p) ^9 



Q 

2' 



where / and Q are the 12-bit two's complement values represented as integers in the range -2^1 to 211-1. 

NOTE: Given that the rms value of x^ ; is equal to 1 (as required by [1]), the signal-to-quantization-noise ratio is 
approximately 59 dB, which should be adequate for all applications. 

The auxiliary stream data field shall be encapsulated into one or more T2-MI packets in the same order as the filling of 
the OFDM cells in the DVB-T2 signal. No stuffing shall be used. 

If more than one T2-MI packet is used for a particular auxiliary stream the payload of T2-MI packets with an unfinished 
stream must end with a completed cell. The next cell value of that stream will then start at the beginning of the payload 
of the next T2-MI packet with packet_type 01 jg with the same aux_id. 

The cell values for auxiliary streams must be the same for all transmitters in a single frequency network when sent over 
the T2-MI using T2-MI_packet_type 01 jg. If it is required, however, that the cell values are to differ, as allowed by [1], 
the auxiliary stream data must be sent to the modulators in an alternative way. 

5.2.3 L1 -current T2-MI packets 

T2-MI packets with a packet_type of lOjg shall contain LI pre- and post-signalling data to be inserted (as described in 
clause 5.3) into the P2 symbols of the T2-frame indicated by frame_idx and describing the same ("current") T2-frame. 

The T2-MI packet payload is shown in figure 6. 



frame idx 



rfu 



LI -current data 



-8 bits — * i < 8 bits — **< variable- 



Figure 6: L1-current data payload 

framejdx (8 bits) indicates the FRAME_IDX according to [1] of the T2-frame in which the LI signalling data is 
carried. This is also the T2-frame that the LI signalling data describes. 

rfu (8 bits) bits reserved for future use and shall all be set to O2. 
Ll-current_data contains fields in the order given in table 2. 

NOTE 1: The PI signalling is generated by the modulator from the SI and S2 fields in the LI pre-signalling (see 
clause 7.2.2 of [1]). 
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Table 2: L1 -current data fields 



Field 


Field lengtli (bits) 


Format 


Description 


L1PRE 


168 


bflbf 


LI pre-signalling bits in the order defined in 
clause 7.2.2 of [1], excluding the CRC. 


L1C0NF LEN 


16 


uimsbf 


Length of LI configurable signalling in bits 


L1C0NF 


ix\L\_CONF _LEN li~\ 


bflbfzpb 


LI configurable post-signalling fields, in the 
order defined in clause 7.2.3.1 of [1]. 


L1DYN CURB LEN 


16 


uimsbf 


Length of LI -dynamic, current frame. 


L1 DYN_CURR 


%x\l\DYN _CURR _LEN l%\ 


bflbfzpb 


LI -post "dynamic, current frame" fields in 
the order defined in clause 7.2.3.2 of [1]. 


L1EXT LEN 


16 


uimsbf 


Length of LI extension field, in bits. 


L1EXT 


%x\l\_EXT _LENl%\ 


bflbfzpb 


LI -post extension field as defined in 
clause 7.2.3.4 of [1]. 



The LI PRE, LICONF and L1DYN_CURR fields are mandatory in all LI -current T2-MI packets and shall be coded in 
accordance with clauses 7.2.1, 7.2.3.1 and 7.2.3.2 respectively of [1]. 

NOTE 2: The L1DYN_CURR field will not be transmitted in P2 in TFS mode, but is mandatory because the 
information will be used by the modulator for Interleaving and Frame -Building. 

5.2.4 L1 -future 

T2-MI packets with a packet_type of 1 1 jg shall contain LI post-signalling data to be inserted (according to clause 7.2.3 

of [1]) into the P2 symbols of the T2-frame indicated by framejdx, and/or in-band signalling data to be inserted into 
the first BB-Frame of the Interleaving Frame beginning in that T2-frame. The signalling contained comprises those 
fields that describe future T2-frames, and might therefore not be available at the time the LI -current T2-MI packet is 
sent. The T2-MI packet payload is shown in figure 7. 



frame_idx 



rfu 



L1-future_data 



-8 bits- 



-8 bit s > i < 



-variable- 



Figure 7: Li-future data payload 

framejdx (8 bits) indicates the FRAMEJDX according to [1] of the T2 frame in whose P2 symbols the LI dynamic 
post-signalling data is carried. It also indicates the first T2-frame carrying the Interleaving Frame whose first BB-Frame 
will contain the in-band signalling. 

Which T2-frame is described by the dynamic post-signalling and in-band signalling will depend on the use of TFS as 
described in clauses 7 and 5.2.3 respectively of [1]. Which T2-frame or frames are described by the in-band signalling 
will also depend on the interleaving parameters (Pj and /jump) for the PLP in which they are inserted, as described in 
clause 5.2.3 of [1]. 

rfu (8 bits) bits reserved for future use and shall all be set to O2. 
Ll-future_data contains fields in the order given in table 3. 
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Table 3: L1 -future data fields 



Field 


Field lengtli (bits) 


Format 


Description 


L1DYN_NEXT_LEN 


16 


uimsbf 


Length of "dynamic, next frame" field. 
Set to zero if LI DYN_NEXT block is 
absent. 


L1DYN_NEXT 


8x LWYN_NEXT_LEN/8] 


bflbfzpb 


LI -post "dynamic, next frame" fields. 
Optional in single-RF mode, 
mandatory in TFS. 


L1 DYN_NEXT2_LEN 


16 


uimsbf 


Length of "dynamic, next-but-one 
frame" in TFS mode. Set to zero if 
LI DYN NEXT2 block is absent. 


L1DYN_NEXT2 


8 X [lIDYN _ NEXT2 _ LEN /s] 


bflbfzpb 


LI -post "dynamic, next-but-one 
frame" fields, in the order defined in 
clause 7.2.3.2 of [1]. Optional in TFS, 
and shall not be present in single-RF 
mode. 


NUMJNBAND 


8 


uimsbf 


Number of PLPs for which in-band 
signalling is present in the following 
loop. 


For 

i=1..NUM INBAND{ 






In-band signalling loop. 


PLPJD 


8 


uimsbf 


PLP ID for the PLP containing the 
in-band signalling data given by the 
following INBAND field. 


INBAND_LEN 


16 




Length of following INBAND field in 
bits. 


INBAND 


8x\ INBAND _LEN/8 


bflbfzpb 


In-band signalling fields for the PLP 
indicated by PLPJD, in the order 
defined in clause 5.2.3 of [1]. 


1 









Only PLPs for which the T2-frame indicated by frame_idx is the first T2-frame to which an Interleaving Frame is 
mapped shall appear in the in-band signalling loop. 

The L1DYN_NEXT and L1DYN_NEXT2 fields shall be coded in accordance with clause 7.2.3.2 of [1]. The INBAND 
fields shall be coded in accordance with clause 5.2.3 of [1]. 

5.2.5 DVB-T2 timestamp 

T2-MI packets with a packet_type of 20^^ shall carry the DVB-T2 timestamp, used to synchronize the output of 
DVB-T2 modulators. Two mechanisms are defined; absolute and relative. 

The T2-MI packet payload for this data is shown in figure 8. 



rfu 




T2_timestamp 






utco 


seconds_since_2000 


subseconds 


<4 bits> 




Ar\ hit" ■^'■■^ 


0-7 u:4-^ 




J HO u:+^ w 
















': 



Figure 8: DVB-T2 timestamp payload 

rfu (4 bits) bits reserved for future use and shall all be set to O2. 

bw (4 bits) indicates the system bandwidth, in accordance with clause 9.5 of [1]. This also defines the units of the 
subsecond field of the T2 timestamp as shown in table 4. 
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Table 4: Bandwidths and subsecond field units for the T2 timestamp 



Bandwidth 


bw field 


T2 Elementary 
period, T 


subseconds 
unit, Tjyj, 


1.7 MHz 


0l6 


71/131 US 


1/131 MS 


5 MHz 


1l6 


7/40 MS 


1/40 MS 


6 MHz 


2l6 


7/48 MS 


1/48 MS 


7 MHz 


3l6 


7/56 MS 


1/56 MS 


8 MHz 


4l6 


7/64 MS 


1/64 MS 


10 MHz 


5l6 


7/80 MS 


1/80 MS 



seconds_since_2000 (40 bits) is a count of the number of seconds since 2000-01-01 T 00:00:00 UTC as an unsigned 
40-bit quantity and is used to define an absolute time of emission. This count shall increase for every SI second that 
elapses. A value of 0000000000 jg indicates a relative timestamp, defined only by the subseconds field below. 

subseconds (27 bits) defines the number of subsecond units since the time expressed in the seconds field. The value is 
expressed as an unsigned integer. 

T2_timestamp: Taken together, the seconds_since_2000 and subseconds fields define the DVB-T2 timestamp and the 
time of emission of a DVB-T2 transmission. Annex F details the relationship between the DVB-T2 timestamp and other 
time standards. 



When the seconds_since_2000 field is non-zero, the emission time shall be given by 
seconds since 2000 + subseconds x T, 



suh^ 



When the seconds_since_2000 field is all zeros, the emission time shall be subseconds x T^^^^ after the SI second 
boundary preceding it. 

NOTE 1 : The SI second boundary can be given by the relevant edge of a 1 pulse per second signal. 

The emission time shall be the time at which 50 % of the energy of the first time sample from the IFFT of the "C" part 
of the PI preamble symbol of the first T2 transmission frame of the relevant superframe shall have been radiated on air. 
All T2 frames within a superframe shall have the same timestamp value. The timestamps of subsequent superframes 
shall be increased by the duration of the superframe. 

NOTE 2: Based on the knowledge of the DVB-T2 Timestamp of a particular superframe, and the LI signalling 
pertaining to a particular T2 frame, a modulator should be able to determine the required emission time 
for any such T2 frame even if it misses the beginning of a superframe, e.g. after a restart. To do this, the 
modulator will then need to take into account the frame index and the frame length of the T2 frame as 
well as the total lengths of any FEE parts having occurred in the superframe before the current T2 frame. 

utco (13 bits) is the offset (in seconds) between UTC and the seconds_since_2000 field. The value is expressed as an 
unsigned integer. As of February 2009, the value shall be 2 and shall change as a result of each new leap second 
proscribed by the International Earth Rotation and Reference Systems Service (lERS). 

NOTE 3: The value contained in this field has no effect on the time of emission from the modulator but it may be 
useful to a modulator implementation where only a source of UTC time is available. 

5.2.5.1 Null timestamp 

When it is not required to synchronize the output of multiple DVB-T2 modulators, the DVB-T2 timestamp shall be 
signalled as null by setting all bits of the T2_timestamp and utco fields to I2. 

A DVB-T2 timestamp packet must always be sent (whether carrying a Null timestamp or otherwise) to indicate the 
bandwidth of the T2 transmission to the T2 modulator. 
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5.2.6 Individual addressing 

T2-MI packets with a packet_type of 21 jg shall carry individual addressing data. The T2-MI packet payload is shown 
in figure 9 and the individual addressing data is in the same format as clause 6.1 of [3]. 



rfu 


individuaLaddressing 
Jength 


individual_addressing_data 



,^8 bits>-K- 



-8 bits- 



->^ 



-variable- 



fori=1..l{ 
txjdentifier 

functionjoopjength 
forf=1..F{ 
function() 
} 
} 



(16 bits) 
(8 bits) 
(variable) 



Figures: Individual addressing payload 

individual_addressing_length (8 bits) indicates the length of the individual_addressing_data field in byes. 

individual_addressing_data (variable bits) is composed as follows: 

txjdentifier (16 bits) is a word used to address individual transmitters. A value of "OOOO^g" is used as a broadcast 
address to address all transmitters in the network. 

functionjoopjength (8 bits) indicates the length of the following loop of functions in bytes. 

functionO is the addressing function and is dependent on the application. They are defined in clauses 5.2.6.1 and 
5.2.6.2. 



5.2.6.1 



Existing addressing functions 



The format of the individual addressing functions is in accordance with clause 6.1 of TS 101 191 [3]. Table 5 indicates 
which of the currently defined functions are also applicable to DVB-T2. 

Table 5: Existing individual addressing functions 



Function 


function tag value 


Applicable to DVB-T2? 


Transmitter time offset 


00i6 


yes 


Transmitter frequency offset 


01l6 


yes 


Transmitter power 


02i6 


yes 


Private data 


03i6 


yes 


Cell id 


04i6 


yes 


Enable 


05i6 


yes 


Bandwidth 


06i6 


no 



5.2.6.2 



Addressing functions specific to DVB-T2 



Some new functions are defined to fully support DVB-T2 as depicted in table 6. Whilst these have the same basic 
structure as those defined in clause 6.1 of TS 101 191 [3], the data they carry is specific to their function in a T2 system. 

Table 6: Individual addressing functions specific to DVB-T2 



Function 


function tag value 


Transmitter PAPR 


10i6 


Transmitter IVIISO group 


11l6 
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Each functionO is constructed from three fields as follows: 

function_tag (8 bits) is the value identifying the particular function in use as defined in tables 5 and 6. 

functionjength (8 bits) defines the total length of the function() in bytes, including the function_tag, 
functionjength and function_body() fields. 

function_body() is specific to the particular individual addressing function as defined in the clauses below. 



NOTE: For each of the existing individual addressing functions defined in TS 101 191 [3], function_body() 
comprises all the fields that follow the functionjength field. 



5.2.6.2.1 



PAPR function 



The Transmitter PAPR function is used to signal the Active Constellation Extension (ACE) parameters to the DVB-T2 
modulator (see clause 9.6.1 of [1]). ACE has 3 parameters, G, L and V^^,- that must be conveyed to all the modulators 
that are part of an SEN to ensure that they produce identical on-air signals. Table 7 shows how these parameters are 
conveyed in the PAPR addressing function. 

Table 7: PAPR function 



Syntax 


Number of bits 


Format 


tx_PAPR functionO { 






function tag 


8 


uimsbf 


function length 


8 


uimsbf 


function body() { 






ACE gain 


5 


uimsbf 


ACE maximal extension 


3 


uimsbf 


ACE clipping threshold 


7 


uimsbf 


reserved future use 


1 


bflbf 


1 






} 







ACE_gain (5 bits) shall be a value between and 3 1 that represents the ACE gain, G. 

ACE_maximal_extension (3 bits) shall be a value that represents the ACE maximal extension value, L as follows: 
ACE_maximal_extension = {L- 0,7) / 0, 1 . 

ACE_clipping_threshold (7 bits) shall be a value that represents the ACE cUpping threshold, V^^- as follows.- 
ACE_clipping_threshold = 20 logio(V^/,/, / V^,)/0,1. 

reserved_for_future_use (1 bit) is reserved for future use and shall be set to 0^ until defined. 



5.2.6.2.2 



MISO group function 



This function allows the MISO group (see clause 9.6.1 of [1] and annex D) to be signalled to a DVB-T2 modulator. 
Table 8 shows the format of the individual addressing function. 

Table 8: MISO group function 



Syntax 


Number of bits 


Format 


tx PAPR functionO { 






function tag 


8 


uimsbf 


function length 


8 


uimsbf 


function bodyO { 






IVIISO group 


1 


bflbf 


reserved future use 


7 


bflbf 


} 






} 







MISO_group (1 bit) indicates the MISO group. Value O2 indicates MISO group 1. Value I2 indicates MISO group 2. 
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reserved_for_future_use (7 bits) is reserved for future use and shall all be set to O2 until defined. 

5.2.7 FEF part: Null 

T2-MI packets with a packet_type of 30 ^g shall carry information related to a FEF part, in accordance with [1], 
clause 8.4, during which no signal shall be generated by the modulator apart from the PI preamble. 

The T2-MI packet payload is shown in figure 10. 



fef_idx 



rfu 



sljield 



s2_field 



-8 bits » j < 9 bits-H<-3 bits->:<-4 bits-> 

Figure 10: FEF part: Null payload 

fef_idx (8 bits) indicates the index of the FEF part within the superframe. The first FEF part in a superframe shall have 
a fef_idx value of "0" and this shall increment by 1 for each subsequent FEF part. 

rfu (9 bits) bits reserved for future use and shall all be set to O2. 

sl_field gives the value of the S 1 field in the PI preamble of the FEF part according to clause 7.2. 1 of [1]. 

s2_field gives the value of the S2 field in the PI preamble of the FEF part according to clause 7.2. 1 of [1]. 

Unless the content for the corresponding FEF part is specified by another means, the modulator shall generate a PI 
preamble according to the sl_field and s2_field followed by zero modulation values for the remainder of the FEF part. 



5.2.8 FEF part: l/Q data 

T2-MI packets with a packet_type of 31 ^g shall carry information related to a FEF part, in accordance with [1], 
clause 8.4, together with I/Q data to be transmitted during the FEF part. 

The T2-MI packet payload is shown in figure 1 1 . 



fef idx 



-8 bits- 



rfu 



s1 field 



9 bits->^<-3 bits-X-4 bits-^< 



s2 fieid 



fef_part data 



-variabie- 



Figure 11 : FEF part: l/Q data payload 

fef_idx (8 bits) indicates the index of the FEF part within the superframe. The first FEF part in a superframe shall have 
a fef_idx value of "0" and this shall increment by 1 for each subsequent FEF part. 

rfu (9 bits) bits reserved for future use and shall all be set to O2. 

sl_field gives the value of the "SI" field in the PI preamble of the FEF part according to clause 7.2.1 of [1]. 

s2_field gives the value of the "S2" field in the PI preamble of the FEF part according to clause 7.2.1 of [1]. 

fef_part_data carries the IQ data for each FEF part. It shall consist of the complex sample values in time order, starting 
from the first sample after the end of the PI preamble, at a sampling rate of 1/T as defined in clause 9.5 of [1]. Each 
sample value shall be sent as a 12-bit two's complement value / for the real part immediately followed by a 12-bit two's 
complement value Q for the imaginary part of the complex number. The sample value, pp£p(f), shall be given by: 



Re(Pf£f(0)=^9 



Im(;?^£f(0) = ;,9 



1_ 

Q 

2" 
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where / and Q are the 12-bit two's complement values represented as integers in the range -2^' to 2^1-1. The transmitted 
signal s{t) during the T2 frames is defined in clause 9.5 of [1], and the signal during the FEF parts, using the same 
scaling, shall be given by: 



m=^t{e^f' P,^J4^ 



NOTE: This allows a peak modulation magnitude, with any phase, of 12dB above the rms level of the signal 
during the T2-frames. The quantization noise is approximately 59dB below the rms level of the 
T2-frames. 

When this T2-M1 packet type is used, the mean power of the complex samples E(l/7p£pl^) shall not exceed unity. 

If more than one T2-M1 packet is used for a particular FEF part, the payload of T2-M1 packets with an unfinished 
stream shall end with a completed sample. The next sample value for that FEF part shall then start at the beginning of 
the payload of the next T2-M1 packet with packet_type 3 1 jg with the same fef_idx. All T2-M1 packets of type 3 1 jg with 
a given fef_idx shall have the same value of sl_field and s2_field. The total number of complex samples shall equal 
FEF_LENGTH-2048 where FEF_LENGTH is the Ll-post configurable signalling field defined in clause 7.2.3.1 of [1]. 

5.3 Generation of L1 signalling from the T2-l\/ll packets 

The behaviour of a DVB-T2 modulator operating with a T2-M1 signal as described by the present document is defined 
by the DVB-T2 specification [1] of the signal-on-air combined with the definition of the content of the various T2-MI 
packets, together with certain configuration parameters for the individual modulator. 

Modulators will generate the LI -pre signalling by assembling: 

• the LI PRE field from LI -current (type lO^g) T2-M1 packet having framejdx equal to FRAMEJDX of the 
T2-frame being generated; and 

• the CRC generated by the modulator itself. 

Modulators will generate the Ll-post signalling for a given T2-frame by assembling: 

• the LI CONE from the relevant LI -current (type 10 jg) T2-M1 packet; 

• the appropriate combination of L1_DYN_CURR from the relevant LI -current (type lO^g) T2-M1 packet, and 
L1_DYN_NEXT and L1_DYN_NEXT2 from the relevant LI -future (type 1 1 jg) T2-M1 packet, as given in 
table 9; 

• the L1_EXT from the relevant Ll-current (type lOjg) T2-M1 packet, if present; and 

• the CRC generated by the modulator itself; 

where the relevant packet is the one having framejdx equal to FRAMEJDX of the T2-frame being generated. 

Table 9: The combination of L1-dynamic fields used to generate the L1-post signalling 





L1 REPETITION FLAG=0 


L1 REPETITION FLAG=1 


NUM RF=1 (non-TFS) 


L1 DYN CURB 


L1 DYN CURB, L1 DYN NEXT 


NUM_RF>1 (TFS) 


L1 DYN NEXT 


L1 DYN NEXT, L1 DYN NEXT2 



NOTE 1: In TFS, the L1_DYN_CURR field is never transmitted in the P2 symbols. However, the information in 
this field is needed by the modulator for interleaving and frame building and so is always sent in the 
Ll-current T2-M1 packet. 

A modulator may replace the CELLJD field in the LI -pre signalling and/or the FREQUENCY field(s) in the 
configurable Ll-post signalling. Modulators operating in the same Single -Frequency Network (SEN) shall all use the 
same values of these fields. 

NOTE 2: If these fields are modified within a modulator this is done prior to calculation of the CRCs. 
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5.4 Transmission order of T2-l\/ll packets 

The T2-MI packets with packet_type OOjg (BB-Frames) for a given PLP shall be sent in the original order of the 
Baseband Frames they encapsulate. The transmission of such T2-MI packets is mandatory. 

The T2-MI packets with packet_type 01 ^g (Auxiliary streams) with a given value of aux_id shall be sent in the order of 
increasing cell address of the first cell that they carry. 

T2-MI packets of type OOjg for different PLPs and T2-MI packets of type 01 jg for different values of aux_id may be 
multiplexed together in any order, provided the above conditions are met. 

NOTE: The frame_idx in T2-MI packets of type OO^g may change at different times for different PLPs. For 
example, type 00 j 5 packets for one PLP for frame m+l may be sent before type 00 jg packets for a 
different PLP for frame m. This is particularly likely when multi-frame interleaving is in use. 

Immediately following the last transmitted T2-MI packet with packet_type OO^g or 01 ^g to be used for the construction 
of a particular T2 frame, the following T2-MI packets shall be sent in the order set out below: 

• one T2-MI packet with packet_type 20jg (DVB-T2 timestamp) pertaining to the same T2 frame. The 
transmission of such a T2-MI packet for each T2 frame is mandatory. Where SFN synchronization is not 
required the DVB-T2 timestamp shall be null (see clause 5.2.5.1); 

• one T2-MI packet with packet_type lO^g (Ll-current data) pertaining to the same T2 frame. The transmission 
of one such T2-MI packet per T2 frame is mandatory. 

If in-band signalling, LI -repetition or TFS are used, a T2-MI packet of type 1 1 jg (LI -future) for the T2-frame shall be 
sent at a later time. 

When the T2-MI packet with packet_type 1 1 ^g (LI -future) is used it shall always be the last T2-MI packet with a given 
frame_idx and the T2-MI packet of type lO^g (Ll-current) shall be the second-to-last packet with a given frame_idx. 
Otherwise the T2-MI packet of type lO^g (Ll-current) shall be the last T2-MI packet with a given frame_idx. 

5.5 Timing of T2-l\/ll packet transmission 

In this clause, T^i^^y, T^[j^2^ ^min3' ^maxl' ^max2 ' ^max3 '^^'^ ^max4 represent specification values for a modulator and 
should be quoted by modulator manufacturers. Network operators should design the timing of a network carrying 
T2-MI taking into account the values for each of the modulators in the network. 

The T2-MI packets of type OOjg, 01 jg, lOjg and 20jg with a given frame_idx shall be sent so as to arrive at the 
modulator no later than r^^j^j before the beginning of the corresponding T2-frame is due for transmission. 

The T2-MI packet of type 1 1 jg, if used, with a given frame_idx, shall be sent so as to arrive at the modulator no later 
than rj^ij,2 before the beginning of the corresponding T2-frame is due for transmission. 

T2-MI packets of type 30jg, and 3 1 ^g with a given fef_idx shall arrive no later than T^^^^^ before the corresponding FEF 
part is due for transmission. 

T2-MI packets of type OOjg with a given frame_idx shall arrive no earlier than T^+T^.^^^ before the beginning of the 
corresponding T2-frame is due for transmission, where Tjp =^iX^iump^^F i^ '■^^ duration of one Interleaving Frame for 
the corresponding PLP. 

T2-MI packets of type 01 jg with a given frame_idx shall arrive no earlier than T^.^^2 before the beginning of the 
corresponding T2-frame is due for transmission. 

T2-MI packets of type lOjg, 11 jg, and 20jg with a given framejdx shall arrive no earlier than T^^^ before the 
beginning of the corresponding T2-frame is due for transmission. 
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T2-MI packets of type 30jg, and 3 1 ^g with a given fef_idx shall arrive no earlier than T^.^^^ before the corresponding 
FEF part is due for transmission. 

For the purposes of this clause, the time of arrival of a T2-MI packet at the modulator shall be defined as the time at 
which the packet is dehvered by the underlying DVB data piping protocol (see clause 6.1). 



Transport of T2-MI packets 



The structure of the T2-MI protocol stack described in clause 4.3 allows two mechanisms for distribution; one for 
traditional ASI interfaces, the other for IP based networks. 

Both mechanisms rely on first inserting the T2-MI packets into DVB/MPEG-2 TS packets which can then be interfaced 
to a distribution network via such interfaces as described in EN 50083-9 [i.2]. 

The resulting TS can then be further encapsulated into an IP stream using the DVB IPTV standard, TS 102 034 [5]. 

6.1 Encapsulation of T2-MI packets in l\/IPEG-2 TS 

The insertion of T2-MI packets into MPEG-2 TS packets shall be in accordance with EN 301 192 [4], clause 4, "Data 
Piping". This mechanism allows for the insertion of data directly into the payload of MPEG-2 TS packets with the 
minimum of additional overhead. 

6.1.1 Description 

The T2-MI packets are inserted, one after another, into the payload of MPEG-2 TS packets. Each new T2-MI packet 
shall start immediately following the previous one. A TS packet may contain more than one T2-MI packet. T2-MI 
packets that are too big to fit into the payload of a single TS packet shall be split across multiple TS packets as required. 

Since the length of each T2-MI packet is variable (indicated by the payloadjen field in the T2-MI packet header), the 
start of a TS packet's payload does not necessarily coincide with the start of a T2-MI packet. To enable synchronization 
within a device receiving T2-MI, the "payload_unit_start_indicator" bit in the TS header shall be used to indicate that a 
new T2-MI packet starts somewhere within the current TS packet. When this is the case an 8-bit pointer shall be 
positioned as the first payload byte of the TS packet, indicating the offset from the start of the TS payload to the first 
byte of the first T2-MI packet. This 8-bit pointer field (uimsbf) shall indicate the number of bytes immediately 
following the pointer field until the first byte of the first T2-MI packet that is present in the payload of the Transport 
Stream packet (i.e. a value of OOjg in the pointer field indicates that the T2-MI packet starts immediately after the 
pointer field). This is illustrated in figure 12. 
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Figure 12: Encapsulation of T2-l\/!l Packets in l\/!PEG-2 TS 

Using this mechanism the T2-MI packet can begin anywhere in the TS packet. There is no requirement to have T2-MI 
packets beginning at the start of a TS packet and no need for unnecessary stuffing. 

NOTE 1: Since the TS packets containing T2-MI packets are carrying a data type not defined by MPEG, 

EN 301 192 [4] allows the use of the "payload_unit_start_indicator" bit in this "service private way". 

When a T2-MI packet ends at the last-but-one byte of a TS packet and starts in a previous TS packet, the one remaining 
byte does not allow space for both the insertion of the 8-bit pointer field and the first byte of the next T2-MI packet. In 
this case the size of the payload of the TS packet shall be reduced by one byte through the use of adaptation field 
stuffing [7] such that the current T2-MI packet finishes at the end of the TS packet payload. The next T2-MI packet 
shall start in the next TS packet having the same PID. 
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NOTE 2: Arbitrary amounts of padding may also be added, if required, at this layer through the use of arbitrary 
numbers of stuffing bytes in the adaptation field of the transport stream packet [7]. 

EXAMPLE: A T2-MI packet is being transmitted. Most of the T2-MI packet has been transmitted and only 

50 bytes remain to be sent. The next T2-MI packet is not yet available and there are therefore not 
enough bytes to fill up a TS packet. To allow this TS packet to be transmitted immediately, an 
adaptation field of total length 134 bytes (adaptation_field_length = 133) containing stuffing bytes 
can be inserted before the payload. 

For carriage over managed distribution networks it may be necessary to add a minimum of PSI in order to prevent 
erroneous alarms from being set. This would normally comprise a PAT, and PMT for a single "Program" as defined in 
ISO/IEC 13818-1 [7]. The Stream Type to be used in the PMT is not defined in EN 301 192 [4]. For the purposes of 
interoperability, it should be set to 06jg. 

Similarly, some networks may require the carriage of mandatory DVB SI tables, and reference should be made to 
EN 300 468 [8] for the appropriate values to be used in such tables. 

When NUM_RF=1, the maximum rate of the transport stream carrying the T2-MI shall be 72 Mbps. 

6.2 Encapsulation of MPEG-2 TS in IP packets 

A DVB-T2 modulator may support the transport of MPEG-2 TS over IP. In case the DVB-T2 modulator supports 
IP-based delivery, the transport of MPEG-2 TS over IP shall follow the specification in this clause. The transport of 
MPEG-2 TS over IP relies on the methods specified in TS 102 034 [5]. This clause specifies a protocol for EEC 
protected multicast delivery of MPEG-2 Transport Streams over RTP and is based on IP version 4 according to [5]. IP 
version 6 is not supported. 

Unicast delivery of MPEG-2 Transport Streams over IP is outside the scope of the specification. However, the unicast 
transport may rely on the same protocol as specified in clause 6.2.2. 

6.2.1 Setup Information 

For delivering FEC-protected, multicast MPEG-2 Transport Streams over RTP using the protocols in TS 102 034 [5], 
the following setup information should be provided according to [5], clause 5.2.6.2, table 4; 

• IPMulticastAddress: 

IPMulticastAddress@Source: Optionally the IP unicast address of the source of the TS may be provided. 

IPMulticastAddress ©Address: Provides the multicast address at which the service may be accessed. 

IPMulticastAddress @Port: Provides the port at which the service may be accessed. 

FECBaseLayer: Contains the multicast address and port of the AL-FEC stream. This element shall be 
present if the FECBaseLayer element is present: 

■ FECBaseLayer® Address: IP Multicast Address for EEC Base Layer. If the IP multicast address is 
omitted, then the FEC flow is assumed to be on the same multicast address as the original data. 

■ FECBaseLayer@Source: IP Multicast Source Address for FEC Base Layer. If the IP multicast 
source address is omitted, then the FEC flow is assumed to be on the same multicast source address 
as the original data. 

■ FECBaseLayer@Port: UDP port for FEC Base Layer. 

FECEnhancementLayer: Contains the multicast address and port of the AL-FEC enhancement stream(s). 
This element shall only be present if the FECBaseLayer element is present. This element may be 
repeated for multiple layers. 

■ FECEnhancementLayer® Address: IP Multicast Address for FEC Enhancement Layer. If the IP 
multicast address is omitted, then the FEC flow is assumed to be on the same multicast address as 
the original data. 
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■ FECEnhancementLayer@Source: IP Multicast Source Address for FEC Enhancement Layer. If the 
IP multicast source address is omitted, then the FEC flow is assumed to be on the same multicast 
source address as the original data. 

■ FECEnhancementLayer@Port: UDP port for FEC Enhancement Layer. 

■ IPMulticastAddress@FECMaxBlockSizePackets: This indicates the maximum number of stream 
source packets that will occur between the first packet of a source block (which is included) and the 
last packet for that source block (source or repair). 

■ IPMulticastAddress@FECMaxBlockSizeTime: The maximum transmission duration of any FEC 
Block (source and repair packets). 

■ IPMulticastAddress@FECObjectTransmissionInformation The FEC Object Transmission 
Information for the Raptor code. If a FECEnhancementLayer element is included then this element 
shall be included. 

For details of the semantics of these parameters refer to [5]. 

6.2.2 Transport Protocols 

Where the MPEG-2 TS is transported over IP, the MPEG-2 TS shall be encapsulated in RTP (Real-time Transport 
Protocol) according to RFC 3550 [6] as specified in TS 102 034 [5], clause 7.LL 

RTCP sender reports and receiver reports shall not be used. 

FEC protection of the MPEG-2 Transport Stream may be provided according to TS 102 034 [5], clauses E.3 and E.4. 
When a DVB AL-FEC enhancement layer is provided, the FEC Scheme defined in TS 102 034 [5], clause E.4.3.2 shall 
be used. 

DVB-T2 modulators that support the transport of MPEG-2 TS over IP shall support the minimum decoder requirements 
according to [5], clause E.5.1.1, i.e. FEC decoders shall support processing of the DVB AL-FEC base layer packets. 

DVB-T2 modulators that support the transport of MPEG-2 TS over IP may support the enhanced decoder requirements 
according to [5], clause E.5.1.2, i.e. FEC decoders may support processing of the DVB AL-FEC base layer and DVB 
AL-FEC enhancement layer packets. 

6.2.3 Session Initiation and Control 

Session initiation is outside the scope of the specification. The session initiation and control for the multicast 
distribution according to TS 102 034 [5], clause 7.3.1 may be used. 

6.2.4 Network Requirements 

The network requirements for the multicast distribution shall be in accordance with TS 102 034 [5], clause 7.2. 

In case application layer FEC is applied, the network requirements may be relaxed. For configuration examples of 
apphcation layer FEC for different network characteristics, refer to DVB bluebook Al 15 [i.3]. 
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Annex A (normative): 
Calculation of the CRC word 



The implementation of Cyclic Redundancy Check codes (CRC-codes) allows the detection of transmission errors at the 
receiver side. For this purpose CRC words shall be included in the transmitted data. These CRC words shall be defined 
by the result of the procedure described in this annex. 

A CRC code is defined by a polynomial of degree n: 



with n > 1 : 
and: 



G„{x)=x"+g„_ix" ^+... + 82X^+8iX + l 



{0,l}, / = 1 n-1 



The CRC calculation may be performed by means of a shift register containing n register stages, equivalent to the 
degree of the polynomial (see figure A. 1). The stages are denoted by b^... bj^^, where b^ corresponds to 1, b^ to x, b2 to 



b^_l to x"' . The shift register is tapped by inserting XORs at the input of those stages, where the corresponding 



coefficients gi of the polynomial are "1". 
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Figure A.1 : General CRC block diagram 

At the beginning of the CRC-32 calculation all register stage contents are irutialized to ones. 

After applying the first bit of the data block (MSB first) to the input, the shift clock causes the register to shift its 
content by one stage towards the MSB stage (^^_i), while loading the tapped stages with the result of the appropriate 

XOR operations. The procedure is then repeated for each data bit. Following the shift after applying the last bit (LSB) 
of the data block to the input, the shift register contains the CRC word which is then read out. Data and CRC word are 
transmitted with MSB first. 

The CRC code used in the T2-MI packet is based on the following polynomial: 

G32(x) = x'' + x'' + x'' + x'' + x'' + x'' + x" + x"' + x' + x' + x' + xVx' + x + l 

NOTE: The CRC-32 coder defined in this annex is identical to that specified in annex F of the DVB-T2 system 
specification [1]. 
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Annex B (normative): 

T2 Modulator Information Packet (T2-I\/IIP) 

B.1 Use of the T2-I\/IIP for over the air synchronization 

The T2-MI packets, as described in the main body of the present document, are only used by the modulator and not 
broadcast from the transmitter. For use cases where several repeaters are receiving a DVB-T2 signal from a main 
transmitter and retransmitting it on a common second frequency, in an SFN, there is a need to make this retransmission 
from the repeaters in a time-synchronized way. This situation is detailed in figm-e B.l. 

There are two types of repeater. They may be: 

• regenerative repeaters, i.e. demodulating the DVB-T2 signal and the re-modulating the demodulated transport 
streams to form a regenerated DVB-T2 signal which is then retransmitted; or 

• transposers, i.e. they would shift frequency, amplify, delay and transmit the received DVB-T2 signal without a 
full re-modulation process taking place. 




SFN relay transmitters 
(repeaters) on frequency fz 



^ 



Homes in shadow of 
main transmitter 





Receivers on 
frequency fi 



Figure B.1 : SFN Relays taking input over the air from the IVIain transmitter 

In this situation, the relay transmitters do not have access to the T2-MI packets that were used by the modulator at the 
main transmitter to generate the on-air, physical layer, T2 signal. 

Because the physical layer signal has been defined at the main transmitter, the only synchronization data required by the 
relay is the time of emission. This is carried by a special Transport Stream packet (the T2-MIP) which is carried in the 
over-air DVB-T2 signal. 

This TS packet can be decoded by a demodulator in each repeater to extract the required emission time of a particular 
superframe of the DVB-T2 signal. Based on this information, and on the knowledge of the timing of the 
currently-received superframe, each repeater can apply the appropriate time delay to ensure emission of the superframe 
at the required time. 

This version of the T2-MI specification only defines the T2-MIP to be carried over transport streams, which is derived 
from the equivalent packet used in DVB-T networks [3]. There is currently no equivalent specification for such a 
mechanism to synchronize networks carrying services over other transports, such as GSE [2]. 

See figure B.2 for the architecture of such a network. 
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NOTE: The T2-MIP inserter resides in the T2 Gateway, as it is this unit that defines the construction of the T2 

Frame and Superframe, and hence the timing relationship of TS packets to the physical layer modulation. 
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Figure B.2: Generic architecture of over-air distribution of the T2-I\/!IP to a SFN Sub-networic 

Under this condition, it is envisaged that the receiver at the relay station would deconstruct the incoming DVB-T2 
signal into the constituent parts such that it could effectively pass an equivalent of the T2-MI signal on to the relay's 
modulator. This is necessary to ensure that every relay's modulator constructs the air interface identically at each station 
in the SFN. 



B.2 T2-MIP Definition 



B.2.1 Field description 

The T2-MIP is an MPEG -2 compliant Transport Stream (TS) packet [7], made up of a 4 byte header and 184 data bytes. 
The organization of the MIP is shown in table B.l. 
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Table B.1 : DVB-T2 Modulator Information Packet (T2-MIP) 



Syntax 


Number of bits 


Identifier 


t2 modulator information pacl<et() { 






transport pacl<et lieader 


32 


bslbf 


synctironization id 


8 


uimsbf 


section lengtti 


8 


uimsbf 


t2 timestamp mip length 


8 


uimsbf 


t2 timestamp mip 


88 


bslbf 


rfu length 


8 


uimsbf 


for i = L.rfujength { 

rfu byte 
1 


8 


uimsbf 


individual addressing length 


8 


uimsbf 


forj = 1 ..individual_addressing_length { 

individual addressing byte 
} 


8 


uimsbf 


ore 32 


32 


rpchof 


for k = 1 ..stuffingjength { 

stuffing byte 
} 


8 


uimsbf 


} 






NOTE 1 : Optional parameters are shown in italic. 

NOTE 2: The total length of a T2-MIP shall always be 188 bytes. 



transport_packet_header (32 bits) shall comply with ISO/IEC 13818-1 [7], clause 2.4.3.2, tables 3 and 4. 

The PID value for the T2-Modulator Information Packet (T2-MIP) shall be 15 ^g. 

The payload_unit_start_indicator is not used by the SFN synchronization function and shall be set to 1 . 

The transport_priority value is not used by the SFN synchronization function and shall be set to 1 . 

The transport_scrambling_control value shall be set to 00 (not scrambled). 

The adaptation_field_control value shall be set to 01 (payload only). 

All other parameters are according to ISO/IEC 13818-1 [7], clause 2.4.3.2. 

The Transport Packet Header (TPH) is mandatory. 
Mandatory T2-MIP fields 
synchronization_id (8 bits) is used to identify the synchronization scheme used. For DVB-T2 the value shall be 02jg 

NOTE 1 : The values of synchronizationjd that apply for different transmissions systems are defined in table 2 of 
TS 101 191 [3]. 

sectionjength (8 bits) specifies the number of bytes following immediately after the section_length field until, and 
including, the last byte of the crc_32 but not including any stuffing_byte. The sectionjength shall not exceed 
182 bytes. 

t2_timestamp_mip_length (8 bits) specifies the length in bytes of the t2_timestamp_mip field that follows. The value 
is currently fixed at 1 1 ^q. 

t2_timestamp_mip (88 bits) is in the identical format to that specified for the complete payload of the T2-MI packet 
with packet type 20jg (see clause 5.2.5). The values expressed by this field refer to the emission time from the repeater 

of the T2 superframe in which the last bit of the payload of the TS packet carrying the T2-MIP appears. 

NOTE 2: The value of the T2 timestamp carried by the T2-MIP may be different from that contained in packet type 
20jg of the T2-MI interface being used as input to the modulator of the main station. 
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rfujength (8 bits) specifies the number of rfu_bytes that follow. A value of OO^g indicates that there are no following 
rfu_bytes. This value is currently fixed at OO^q, i.e. there are no rfu_bytes defined. 

rfu_byte is one byte of a variable number of bytes that are reserved for future use, the number of which is defined by 
the rfujength field. All bytes shall have the value OOjg. 

individual_addressing_length (8 bits) gives the total length of the individual addressing loop in bytes. If individual 
addressing of transmitters is not performed the field value is OOjg and there shall be no individual_addressing_byte 
field. 

individual_addressing_byte contains the bytes of the individual_addressing_data field of a T2-MI packet of type 

21 jg (see clause 5.2.6). 

crc_32 (32 bits) is calculated across all other bits in the packet, including the transport_packet_header but excluding 
the stuffing_byte field, in accordance with annex A. 

stuffing_byte shall have the value FFjg. There shall be a multiple of stuffing_bytes such that the 
t2_modulator_information_packet is exactly 188 bytes long. 

NOTE 3: Whilst the values for the t2_timestamp field and the individual_addressing_bytes shall follow the 
format of the payloads of T2-MI packet types 20jg and 21 jg respectively, the values carried may be 
different to those carried in these packets within the T2-MI. 

B.2.2 Transmission of the T2-I\/IIP over DVB-T2 

The T2-MIP may be transmitted in one or more of the transport streams being sent over DVB-T2. If the T2-MIP is used 
there has to be at least one complete T2-MIP within a T2 superframe. The T2-MIP may be sent at any time within the 
superframe and the timing may be different from superframe to superframe (see the definition of the 
t2_timestamp_mip field in clause B.2.1). 

Where multiple PLPs are used, only one of the PLPs should carry a T2-MIP. If it is carried in multiple PLPs then the T2 
timestamp shall be identical within all PLPs for that superframe. 

NOTE: Where a common PLP is available, this is the preferred location for the T2-MIP. 
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Annex C (informative): 
Local Content Insertion 



When carrying the data for a T2 transmission containing multiple PLPs, local content can be inserted into individual 
PLPs into the T2-MI at a point or points downstream of the T2-gateway. This annex describes one way of achieving 
this. 

A typical application is shown in figure C.l. 



Transport 
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Generic 
streams 
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*■ Modulator — Tx 



Figure C.1 : Local content insertion into a T2-l\/!l stream within a T2-system 

A Local Content Inserter (LoCI) takes as its input the T2-MI stream generated in the T2 -gateway, inserts any local 
content and outputs the resulting T2-MI stream. 

For PLPs that are to carry locally inserted content, the T2-gateway performs the allocation of aU BB frames as normal; 
generating type OO^g T2-MI packets that are both consistent with the LI signalling carried in type lOjg and 1 1 jg T2-MI 
packets and that have the correct timing. 

For a given PLP, the LoCI filters the incoming type OOjg T2-MI packet (carrying Baseband Frames) based on the plp_id 
field (see clause 5.2.1). The BBFRAME data field of every T2-MI packet with a matching plp_id field, is then replaced 
with the local content, using BB frame padding as appropriate. The resulting T2-MI packets must be syntactically 
correct including the calculation of the CRC32 field. 

Where no content is available at the T2-gateway to fill those BB frames pertaining to PLPs that are to be later replaced 
in a LoCI, the BB frames may be of zero DataField Length (DFL = 0), i.e. all padding. 

The LoCI can deal with the timing between the incoming T2-MI and the local transport streams at the input to the LoCI 
in a number of ways. There are three possibilities: 

• The local transport stream is locked to the T2-MI and is at a rate that exactly matches that needed to fill the BB 
frames to be replaced. 

• The local transport stream rate is lower than that needed to exactly fill the BB frames to be replaced and BB 
frame padding is inserted by the LoCI. 

• The local transport stream rate is lower than that needed to exactly fill the BB frames to be replaced and Null 
TS packets are inserted into the BB frames by the LoCI. In this case the LoCI must perform any necessary 
restamping. 

This method of local content insertion has the advantage that the LoCI can be a simple device that does not require any 
knowledge of the SFN timestamp. The disadvantage is that bitrate must be allocated on the link carrying the original 
T2-MI from the T2-gateway for BB frames that are to be replaced with local content. 
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Annex D (informative): 
MISO IVIanagement 



As described, the T2-MI is designed to ensure that modulators in a network all generate identical signals at identical 
times. When the MISO option of DVB-T2 is used, as described in clause 9.1 of [1], the modulators belonging to 
transmitter group 1 are required to generate different signals to those in transmitter group 2. Nevertheless, all 
modulators in the network carry identical Baseband Frames and LI -signalling, with identical timing, so the same T2-MI 
stream is therefore sufficient for all modulators. In addition, each modulator needs to be configured as belonging to 
either group 1 or group 2. This can be seen as another modulator-specific parameter, similar to the power, frequency or 
individual time offset, and may be configured locally at the modulator, by a central control system, or using the 
individual addressing function described in clause in the described in clause 5.2.6. 
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Annex E (informative): 
T2-l\/ll overhead 



This annex gives an indication of the overhead associated with the encapsulation of T2 data within T2-MI packets and 
the additional overhead involved in the transport of T2-MI over MPEG-2 Transport Stream or IP both with and without 
the use of Forward Error Correction (FEC). 



E.1 Encapsulation of T2 data within T2-l\/ll packets 

The encapsulation of T2 data within T2-MI packets (clause 5.1) requires an overhead due to: 

• the T2-MI header (6 bytes); 

• the crc32 field (4 bytes); and 

• the additional fields within the T2-MI packet payload associated with the carriage of BB frames (3 bytes). 
For a typical T2 configuration (as given in clause 4.3 of [i.l]), the payload of the BB-frames is K^^^ = 38 688 bits. 

Excluding LI -signalling and assuming that there is no timestamp or auxiliary stream information, the overhead 
associated solely with carriage of the Baseband Frame data over T2-MI is: 13 / (38 688 / 8) x 100 = 0,27 %. 



E.2 Transport of T2-l\/ll packets 
E.2.1 T2-MI packets over l\/IPEG-2 TS 

Encapsulation of T2-MI packets within 188-byte MPEG-2 TS packets using "data piping" (clause 6.1) requires an 
overhead due to: 

• the TS header (4 bytes). 

Assuming that the overhead due to the pointer to the start of the T2-MI packet is negligible, the resulting overhead is 
therefore 4 / (188 - 4) = 2,2 %. 

NOTE: This value does not take into account any null packets inserted to keep the TS bit rate constant and any 

additional PSI/SI information to be compliant with TR 101 290 [i.4]. The contribution of at least one PAT 
table and one PMT table with a data broadcast descriptor is assumed to be negligible. 

E. 2.1.1 FEC overhead for an ASI link 

Where FEC is required on a physical ASI link carrying the T2-MI packets over MPEG-2 TS, RS( 188,204) can be used. 
This results in an additional 8,5 % overhead. 

The total overhead (T2-MI packets over ASI plus FEC) is (16 + 4) / (188 - 4) = 10,9 %. 

E.2.2 T2-MI packets over l\/IPEG-2 TS to IP 

Encapsulation of TS streams in RTP/UDP/IP packets according to clause 6.2 results in an overhead due to: 

• the RTP header ( 1 2 bytes) ; 

• the UDP header (8 bytes); and 

• the IP header (20 bytes) (without options). 
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Typically, a maximum of 7 MPEG-2 TS packets are encapsulated into one IP packet to remain below the Ethernet MTU 
and hence avoid fragmentation. 

The resulting overhead is therefore: 40 / (188 x 7) = 3 %. 

The total overhead for T2-MI packets over MPEG-2 TS to IP is (40 + 4 x 7) / (184 x 7) = 5,3 %. 

When the Ethernet header is taken into account, the total overhead for T2-MI packets over MPEG-2 TS to IP is 

(40 H- 18 H- 4 X 7) / (184 x 7) = 6,7 %. 

E. 2.2.1 FEC overhead 

The additional overhead due to the FEC schemes defined in TS 102 034 [5] can vary a great deal depending on the 
chosen FEC profile. As an illustration two cases are considered below. 

For a 1-D SMPTE 2022-1 code with 20 columns: 

The additional overhead is (40 H- 12 H- 188 x 7) / (20 x (40 + 188 x 7)) = 5 %. 

The total overhead for T2-MI packets over MPEG-2 TS to IP with FEC is 

20 X (40 H- 4 X 7) H- (40 + 12 H-188 x 7) / (20 x (184 x 7)) = 10,6 % (12,1 % including Ethernet header). 

For a 1-D SMPTE 2022-1 code with 4 columns: 

The additional overhead is (40 H- 12 H- 188 x 7) / (4 x (40 + 188 x 7)) = 25,2 %. 

The total overhead for T2-MI packets over MPEG-2 TS to IP with FEC is 

(4 X (40 H- 4 X 7) H- (40 H- 12 H- 188 x 7) / (4 x (184 x 7)) = 31,8% (33,7 % including Ethernet header). 



E.3 Summary of the overheads associated with T2-l\/ll 

The total overhead due to the encapsulation of T2-MI packets over ASI or Ethernet physical layers is shown in 
table E.l. 

Table E.1 : Summary of the T2-MI overhead when transported over different physical layers 



Physical layer 


Total overhead 


FEC scheme 


Additional overhead 
due to FEC 


Total overhead 
including FEC 


ASI 


2,2 % 


RS(1 88,204) 


8,5 % 


10,9% 


Ethernet 


6,7 % 


1-D SMPTE, 20 column 
1-D SMPTE, 4 column 


5% 
25,2 % 


12,1 % 
33,7 % 
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Annex F (informative): 
DVB-T2 Timestamps 

F.1 Relationships 

The relationships between UTC, TAI, GPS Time and the DVB-T2 Timestamp (as defined in clause 5.2.2) are, as at the 
time of writing (February 2009), as follows: 

GPS = TAI -19 s (constant). 

UTC = TAI - 34 s (variable due to leap seconds). 

UTC = GPS -15 s (variable due to leap seconds). 

UTC = DVB-T2 - utco (constant due to varying value of utco). 

DVB-T2 = TAI - 32 s (constant). 

DVB-T2 = GPS -13 s (constant). 

DVB-T2 = UTC + utco (constant due to varying value of utco). 



F.2 Rationale 



Several other standard time/date encodings are in common use, including MJD, UTC, GPS and TAJ. It was agreed that 
none of these adequately addressed the needs of a DVB-T2 system and that it was desirable to define a time format 
specifically for the DVB-T2 Timestamp. The following reasons were given for rejecting other common timebases: 

• MJD is subject to leap seconds making the fractional portion very hard to represent in a fixed-point format. 

• UTC is subject to leap seconds making the number of seconds in a day variable (86 399 / 86 400 / 86 401). 

• GPS Time is subject to "week number wrapping" approximately every 19,7 years. 

• UTC, TAI, MJD and GPS Time all have epochs (start dates) partway through the 400-year leap-year cycle. 

The DVB-T2 Timestamp is not subject to leap seconds but contains sufficient extra information (in the utco field) to 
trivially convert the value to UTC which does include leap-seconds. Conversion to GPS Time and/or TAI is also trivial, 
simply involving the subtraction of a constant value. The epoch for DVB-T2 Time is synchronized with the start of a 
400-year leap-year cycle, making leap-year calculations simpler and less error prone. 
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